1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
Le reste du site
Editeur "inline" ou "balloon block"
Possibilité de regarder une image en grand dans une fenêtre javascript
OU au moins dans une "page" dotée d'un bouton pur sortir (avec GD? avec imagemagick?)
Explorateur de fichiers pour les images
Protection contre les falsifications de requête inter-site - CSRF
ici une explication simple avec un exemple simpliste
(les GET servent à la navigation, les POST à l'action)
https://www.ibm.com/docs/fr/order-management?topic=ssgtjf-com-ibm-help-sfs-cpqsolution-doc-customization-c-wcc-crosssiterequestforgery-html
notre site est-il concerné? le navigateur peut toujours enregistrer les identifiants (cookie ou pas), la session sur le serveur sera donc maintenue
protection: on ajoute un formulaire caché avec une valeur aléatoire cryptée utilisable une seule fois (=jeton)
"Vous pouvez rendre chaque jeton utilisable une seule fois et ainsi éviter de rejouer plusieurs fois la même requête.
Les jetons sont stockés dans le back-office.
Une rotation des jetons est effectuée quand le nombre maximum a été atteint, les plus vieux en premier.
Chaque jeton peut être lié à une URL spécifique.
Si un jeton est intercepté, il ne peut pas être utilisé dans un autre contexte.
Si besoin, les jetons peuvent être attachés à une adresse IP spécifique.
Depuis la version v2.1, les jetons peuvent être réutilisés (par exemple pour les requêtes AJAX).
Si vous n’utilisez pas un framework qui gère la protection CSRF pour vous, jetez un oeil à Anti-CSRF."
une bibli qui fait ça: https://github.com/paragonie/anti-csrf
"sessions, penser aux attaques CSRF (cross-site request forgery):
ça consite à faire qu'un utilisateur connecté avec une session envoie malgré lui une requête GET ou POST qu'un hacker aura cachée par exemple dans une fausse image clicable
- solution: faire qu'un GET seul dans une session ne suffise pas à effectuer une action (les GET ne doivent servir qu'à afficher la bonne page), une attaque sur un POST est possible aussi mais plus difficile et nécessite d'injecter du javascript
- on peut demander à l'utilisateur une vérification supplémentaire avant chaque action, mais c'est plutôt chiant
- il y a la méthode des jetons, "nonces" et horodatage
- vérifier le "référent", c'est à dire l'URL de la page d'où vient normallement la requête"
infos: https://fr.wikipedia.org/wiki/Cross-site_request_forgery
Upload de musique/vidéo
Ajout de liens youtube, spotify, etc
Version avec base de données
Site bilingue (nécessite la base de données)
Editeur tout AJAX (pas juste les images)
Utilisation de l'éditeur sans recharger la page (en
|
